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ABSTRACT 


The Marine Forces Reserve Headquarters Training Centers (MFRHTC) located 
along the southeastern United States coastline must make timely and appropriate 
decisions regarding hurricane preparation operations when they are threatened by tropical 
cyclones. In response to a request from the Marine Forces Reserve Headquarters to help 
their MFRHTCs prepare, the Naval Postgraduate School and the Center for Educational 
Design, Development, and Distribution are developing a location specific hurricane 
decision simulator (HDS) for the MFRHTC in Hialeah, Florida. The purpose of this 
thesis is to identify the types of information and resources necessary for hurricane 
preparations operations and form a conceptual design for a database support system 
(DBSS) that will enable the required information to be collected, stored, and accessed 
by the HDS. Mission engineering analysis, systems engineering, and the military 
decision-making process are used to evaluate and analyze the information, 
resources, and decisions that the commander of the MFRHTC must make in 
preparation for a hurricane. The results of this thesis detail a conceptual design, 
functional baseline for the DBSS, specify the information and resources requirements 
for the DBSS, and illustrate the decision logic of the HDS for the MFRHTC in 
Hialeah. 
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EXECUTIVE SUMMARY 


The Marine Forces Reserve Headquarters Training Centers (MFRHTCs) located 
along the southeastern United States coastline must make timely and appropriate decisions 
in hurricane preparation operations when they are threatened by developing tropical 
cyclones (TCs). In response to a request from the Marine Forces Reserve Headquarters 
(MARFORRES) in New Orleans to help their personnel prepare for tropical cyclones, the 
Naval Postgraduate School and the Center for Educational Design, Development, and 
Distribution developed a hurricane decision simulator (HDS). This HDS was very 
successful and MAREORRES requested similar HDSs be built for their MERHTCs located 
along the southeastern U.S. coastline. The MERHTC in Hialeah, Elorida just northwest of 
Miami was chosen as the pilot because historically Elorida is extremely susceptible to TCs. 
Version one of the HDS was specific to MAREORRES headquarters and information was 
built into the programming code. The team needed a way to transform the HDS from its 
current version to a version that would enable it to be adaptable to new locations. 

The purpose of this thesis is to identify the types of information, resources, and 
decisions necessary for hurricane preparation operations, develop a conceptual design for a 
database support system (DBSS) that will enable the required information to be collected, 
stored, and accessed by the HDS, and develop the DBSS for the MERHTC in Hialeah, 
Elorida. 

Systems engineering, mission engineering analysis, and the military decision 
making process are powerful tools that can be used to examine the information and 
resource requirements and the decision and actions that the commander of a MERHTC 
must make in hurricane preparation operations. 

The information, resources, and decisions required during hurricane preparation 
operations were collected to complete the DBSS during two site visits, one to 
MAREORRES and the other to the MERHTC. Several key decisions were identified that 
the MERHTC must make during hurricane preparation operations. These decisions 
enabled the construction of a decision tree, which determined the decision logic and 



architecture of the programming code. The key decisions that the commander of the 
MFRHTC in Hialeah must make include: 1) Prepare the advanced echelon (ADVON) 
party, 2) Storm proof the headquarters training center (HTC) and personal property, 3A) 
Deploy the advanced party to the alternate command and control location and authorize a 
voluntary evacuation, or 3B) Prepare and stand up the RBE, 4A) Secure the HTC and 
issue a mandatory evacuation order or 4B) Shelter in place, and 5) Transfer command 
and control to the alternate headquarters. 

In creating a conceptual design for the DBSS, it was essential to understand the 
customer need as well as the functions and components associated with the DBSS. 
System planning and architecting lead to the development of a functional baseline for the 
DBSS. A functional analysis of the DBSS illustrated the specific functions and 
components required to build the DBSS. This lead to mapping the functions to 
components. A system trade-off and feasibility analysis was conducted resulting in two 
alternatives: 1) replacing the location specific information built into the programming 
code 2) removing the location specific information from the code and placing it in a 
storage location where the code referenced the information needed during a simulation. 
Alternative two was chosen because it is already a well-established practice in the 
software industry and allows for easier handling of the information. The DBSS operating 
requirements were determined using a mission and systems engineering approach to 
evaluate commonly listed seven areas: 1) mission definition, 2) performance and physical 
parameters, 3) operational deployment or distribution, 4) operational life-cycle, 5) 
utilization requirements, 6) effectiveness factors, and 7) environmental factors as 
identified by Blanchard and Fabrycky (2011). The DBSS requires a storage device to 
store the spreadsheets, a computer to run them, and periodic updates to the information in 
the DBSS. Lastly, an overall conceptual design for the DBSS is presented as part of a 
conceptual design review to ensure that the alternative design selected was correct and 
can progress to the next step, preliminary design. 

Reference 

Blanchard, Benjamin S., and Wolter J. Fabrycky, 2011. Systems Engineering and 

Analysis. 5th ed. Upper Saddle River, NJ: Prentice Hall International Series in 

Industrial and Systems Engineering. 
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1. INTRODUCTION AND BACKGROUND 

A. INTRODUCTION 

When tropical cyclones and hurricanes are forecasted or active in the Gulf of 
Mexico, Caribbean Sea, or the Atlantic Ocean, the Commanders of the Marine Forces 
Reserve Headquarters Training Centers (MFRHTC) located along the southeastern 
United States coastline must make timely and appropriate decisions in preparation for 
possible evacuation and for continuity of operations in another location. In this situation, 
the commanders encounter ever-changing conditions where they must balance the safety 
of their personnel, facilities, and equipment when maintaining sustainable and effective 
operations. Achieving a balance of maintaining sustainable and effective operations 
requires a systematic exploration of the dynamics of military hurricane preparation 
operations along with the decisions and time involved (Comfort, Siciliano, and Okada 
2011). While hurricane preparations activities, actions, and evacuations can be costly, 
failing to properly prepare and act accordingly when threatened by a TC could lead to 
potential loss of life and severe damage to facilities and infrastructure. 

These commanders often make decisions under severe time constraints with 
information that changes by the hour, and the required actions from these decisions can 
have significant lead times. Additionally, the commanders and their staffs change every 
two to three years, often during peak hurricane season. Incoming personnel potentially 
have little to no experience living in an area susceptible to hurricanes. No matter when a 
potential storm or the personnel changeover occurs, the commanders are ultimately 
responsible for ensuring the safety and well-being of the personnel, equipment, and 
facilities while maintaining continuity of operations. This situation brings multiple 
dimensions of uncertainty about the potential impacts to the command, personnel, and 
facilities, which the commanders and staffs must navigate and make challenging 
decisions. 

This thesis will focus on the MFRHTC located in Hialeah, Florida, and use it as a 
case study for developing future Hurricane Decision Simulators (HDS). The HDS is a 
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computer-based training tool designed to give eommanders and their staffs realistie 
experience in decision making during hurricane preparations operations. The MFRHTC 
is partieularly suseeptible to tropieal cyclones (TCs) and hurrieanes beeause it is loeated 
just west of Miami near the southern tip of Florida. The MFRHTC tracks numerous TCs 
every year. With the MFRHTC as a backdrop, this thesis addresses four objectives: 1) use 
a mission engineering analysis process to evaluate and analyze the decisions and actions 
that the commander and staff of the MFRHTC in Hialeah must make in preparation for a 
hurrieane and possible evacuation of the headquarters training center (HTC), 2) use the 
deeomposition of the mission spaee to identify the types of information and resources 
necessary for these operations, 3) create a database support system (DBSS) for the 
development of future HDSs, and 4) create a coneeptual design for the DBSS for future 
HDSs. 

B. BACKGROUND 

1. Tropical Cyclones 

Tropical cyclones are one of nature’s most destructive forces; therefore, 
individuals and communities that are in areas susceptible to TCs must take action and be 
prepared when TCs form. Not only are the areas located along the coastline vulnerable, 
inland areas can be threatened by rain, high winds, flooding, and tornadoes. From 1970- 
2010, the Atlantic Ocean, Caribbean, and Gulf of Mexico have seen on average 11 
tropical storms per year, with six developing into hurricanes (National Weather Service 
2013). The National Hurricane Center (NHC) defined a TC as a “rotating, organized 
system of clouds and thunderstorms that originates over tropical or subtropical waters and 
has a closed low-level circulation” (National Weather Service 2013). The Saffir-Simpson 
Hurricane Scale defines the five categories of hurricanes. The NHC defines the categories 
of tropical depressions, tropical storm, hurricane, and major hurricane: 

• Tropical Depression: maximum sustained wind speed of 38 mph (33 kts) 
or less 

• Tropical Storm: maximum sustained wind speed between 39 and 73 mph 
(34 to 63 kts) 
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• Hurricane: maximum sustained wind speed greater than 74 mph (64 kts), 
but less than 111 mph (96 kts), categories 1 and 2 hurricanes 

• Major Hurricane: maximum sustained wind speed greater than 111 mph 
(96 kts), categories 3, 4, and 5 hurricanes. (National Hurricane Center 
2017a) 

2. Hurricanes and the Marine Forces Reserve Headquarters Training 
Center in Hialeah, Florida 

The MFRHTC facility is located in the city of Hialeah, just northwest of Miami 
and within Miami-Dade County, approximately 10 miles from the coast, 8 miles from the 
Everglades, and is 7 feet above sea-level. Figure 1 illustrates the MFRHTC’s location. 
Because of its climate, ecology, and topography, Florida is highly susceptible to being 
struck by hurricanes. From 1851 to 2015, Florida has been directly hit by 114 hurricanes, 
including 37 major hurricanes (Blake, Fandsea, and Gibney 2011). From 1994 to 2012, 
34 hurricanes have hit southeast Florida, including nine major hurricanes (Miami-Dade 
County 2013). Major hurricane examples include Wilma and Katrina in 2005, Floyd and 
Irene in 1999, and the most destructive to Florida, Andrew in 1992. Hurricane Andrew 
reached category 4 status as it impacted Florida, killing 23 people, reaching winds speeds 
of 164 mph, creating a 17 ft storm surge, and causing $25.5 billion in damages (National 
Hurricane Center 2017b). 
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Figure 1. Marine Forces Reserve Headquarters Training Center Location 
(Also Known as the Naval Operational Support Center Miami). Source: 

Google Maps (2017). 


The MFRHTC is the central location for the Marine reservists in the area and is 

responsible for facilitating the training and readiness of Reserve and National Guard 

Marines. Additionally, the facility deploys, tracks, and receives numerous United States 

(U.S.) military personnel in transit to and from missions throughout the world. The 

MFRHTC is a relatively small facility with 19 fulltime Marines, several military and 

government vehicles, and two buildings (Colonel Jonathon Price, Commander of the 

MFRHTC, personal communication, January 10, 2017). The MFRHTC maintains a 

hurricane preparation and evacuation plan, which is evaluated and updated yearly prior to 

the start of hurricane season. This plan captures how the MFRHTC prepares, the actions 

it must take, and the decisions it must make in preparation for a hurricane and possible 

evacuation. Additionally, the plan anticipates the costs, lead times of those decisions, and 

the timeframe in which the commander must make those decisions. The commander’s 

decisions are largely based on the available forecasts published by the NHC and 

recommendations from the Miami-Dade Office of Emergency Management (MDOEM). 

The current hurricane preparation and evacuation plan does not spell out the exact 
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conditions in which the decisions should be made, nor does it account for the uncertainty 
in the storm forecasts, both of which could have potentially significant effects on when 
and how decisions are made. According to the current commander Colonel Jonathan 
Price, his top three priorities are: 1) safety of personnel, 2) continuity of operations, and 
3) safety of facilities, which includes the HTC and the personal property of the Marines 
(Colonel Jonathon Price, Commander of the MFRHTC, personal communication, January 
11,2017). 


3. The Hurricane Decision Simulator: Applications and Benefits 

Realizing the risk to personnel, equipment, and operations that TCs and 
hurricanes present, in 2014 the Marine Forces Reserve Headquarters in New Orleans 
(MARFORRES) requested support in developing a computer-based training tool that 
would assist commanders and their staffs in experiencing the decision-making process 
through realistic simulated hurricanes. In response to this request, the Naval Postgraduate 
School (NPS), Dr. Eva Regnier from NPS, and Dr. Cameron MacKenzie from Iowa State 
University, and the Center for Educational Design, Development and Distribution 
(CED3) at NPS developed version one of the HDS for MAREORRES. 

The three principal components of the HDS are: realistic storm simulator, a list of 
decisions from which the user can select, and outcomes based on the time the user selects 
a decision. The HDS addresses the decision-making challenges by giving users the 
opportunity to gain decades of valuable experience in a few hours through multiple 
simulations. This is significantly more experience than individuals could get through real 
life training and experience. 

a. Tropical Cyclone Simulator 

The HDS displays a realistic scenario including the TC’s track, size, and intensity, 
with associated forecasts and probability of winds exceeding 39, 58, and 74 mph. The TC 
variables, forecasts, and probability of wind speeds are updated at discrete six-hour 
intervals which correspond with the NHC models and updates. The HDS allows the users 
to make decisions based on the operational procedures of MAREORRES and simulated 
storm forecasts, while stepping through the simulation with new decision opportunities as 


5 



the forecasts are updated, enabling the users to train on plausible storms situations. The 
users receive feedback from the simulation based on the decisions they make, the time 
when those decisions are made, and the TC information. 

b. User Decisions 

The decisions offered within the HDS are the key decision that were identified 
that are based on discussions with the emergency operations personnel and decision 
makers at MARFORRES, and a review of their hurricane planning and preparations 
documents, including a decision support matrix which outlines six key sequential 
preparation decisions, with follow on actions, that the commander can make, beginning at 
approximately 120 hours prior to a TC’s projected landfall. 

The six key decisions include: (with respective time windows) 

1. Deploy the advanced echelon (ADVON) party to a predetermined 
alternate location. (120- 96 hours before landfall) 

2. Deploy liaison officers to link up and communicate with the local 
emergency operations center. (96-72 hours before landfall) 

3. Deploy the emergency relocation staff to the alternate headquarters. (72- 
60 hours before landfall) 

4. Activate the remain behind element (RBE) to secure the headquarters. 
(72-60 hours before landfall) 

5. Order an evacuation or shelter in place at the headquarters. (60-48 hours 
before landfall) 

6. Transfer command to the alternate headquarters. (48 hours before landfall) 
(Regnier and MacKenzie 2017) 

The HDS uses these decisions and allows the user to make them throughout a 
simulation, without biasing the user to any decision during a simulation. The HDS allows 
users to see realistic simulated TCs with forecasts that evolve over time so that they can 
experience the unpredictability and uncertainty of decision making in hurricane 
preparation operations. 

The simulation, designed by Regnier and MacKenzie, and developed for online 

delivery by CED3, starts with a TC formation in the central display, with initial forecast 

projection, as seen in Eigure 2. At the top, the user can choose to view wind speed 
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probabilities of 39, 58, or 74 mph, or the TC predicted path with the error cone. On the 
right of the wind-speed graphics is a color-coded key that depicts the probabilities seen in 
the central display. On the left is a record of events where the user can access TC 
information, recorded decisions taken with the associated follow on actions. On the 
bottom left is the first key decision the user can select, which the use can only select one 
decision at a time. On the bottom is the current TC forecast and information. As the 
simulation progresses, the user is prompted with forecast updates at 6-hour intervals. 


About Hdp Shara •i 


Record of Events ^ 

Current i I22hrs 24% 

Initial Storm Update 


Decision HIM 


Do you want to deploy the 
ADVON (19 personnel) for 
about $25,000? 




NO. CONTINUE 


HURRICANE DECSION SIMULATOR 


PROBABILITIES (of Winds Exceeding Threshold) (7, 


39 mph 


58 mph 


74 mph 


Cone 1 Aug 1200 



MAP VIEW 
AUTO ADVANCE ® 


CURRENT UPDATE 1 Aug 1200 NoAcoons t Details 

‘120-hour probability of 39 mph winds affecting NOLA: 24% 

Expected landfall Storm Center Radius of Max Winds Max Sus. WIrvds 

122hrs (at 32.3*Nx86.7*W) 22.rN x 783*W _S5mi_ 30mph 


Figure 2. Simulation Start. Source: U.S. Marine Forces Reserve (2016). 


The MARFORRES HDS has a specific decision logic, displayed in Figure 3. If 
the user decides to take a preparation action, the decision is recorded and the simulation 
progresses and the user is prompted for the next decision at the next forecast update. If 
the user choses to not take a preparation action and to continue the simulation instead, the 
user is offered the decision whether to take the same preparation action at the next storm 
forecast update. The user can create a compressed timeline by taking preparation actions 
in quick succession that does not align with the MARFORRES decision support matrix if 
the forecasts indicate that the TC grows in strength, is more likely to strike New Orleans, 
or the TC approaches land more quickly than expected. Additionally, due to the 
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uncertainty in TC track forecasts the projected time to landfall that the HDS presents does 
not change in six-hour time steps, but can vary by several hours. A detailed simulation 
example can be seen in the Appendix. 


No. Continue 



Figure 3. MARFORRES HDS Decision Logic. Source: Regnier and 

MacKenzie (2017). 


c. Simulation Outcome and Feedback 

The outcome of the model is based mainly on information from MARFORRES 

subject matter experts in emergency management, logistics, operations, and 

communications. The decisions made by the user during the simulation may result in 

disruptions in operations or monetary costs, or create difficulties in completing the 

hurricane preparation operations. The HDS describes the consequences of the storm 

impacts in general terms. Eor example, if no preparation actions are taken and a category 

3 hurricane strikes New Orleans, the simulation feedback will display: 

MER headquarters in New Orleans can be used for a limited time period. 

Key infrastructure in New Orleans is damaged because of the hurricane. 

Power outages cover much of New Orleans. Communications in the city are 
difficult, and many roadways are flooded. It may be difficult to purchase 
groceries and fuel. Water may also be in short supply. Many MER 
personnel unable to get to work. MER personnel are very preoccupied about 
the safety and well-being of their fa mi lies. Some mission essential functions 
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cannot be performed. The ability of MFR to continue operating at the New 
Orleans headquarters depends on its ability to resupply its generators and 
the status of the local infrastructure (such as when power is restored and the 
availability of water). Local authorities and homeland security officials 
conduct a damage assessment of the city and prioritizes who receives power 
first. (Regnier and MacKenzie 2017, 24) 

The simulation ends after the storm has made landfall or dissipates. The user is 
given feedback based on the time the user made decisions, the impacts of the subsequent 
actions coupled with the decisions, the impacts of the state and city actions taken, and the 
direct storm impacts to New Orleans, such as infrastructure damage. Through the 
feedback, the user can gain experience not only about the decisions, actions, and costs 
that MARFORRES must make or pay, but the impacts of the state and city actions on the 
preparations. After any simulation, the user can begin to understand the effect of the 
timing on their decisions and how MARFORRES personnel and operations are impacted. 

d. HDS Applications and Benefits 

MAREORRES has used version one of the HDS for both individual training and 
group hurricane preparation exercises. The HDS is used by individuals who are assigned 
to the headquarters and have limited experience with tropical storms and hurricane 
preparations. The goal is to get them acquainted with making decisions in a complex 
environment filled with uncertainty (Regnier and MacKenzie 2017). Additionally, the 
HDS is used by MAREORRES in two annual group tabletop exercise. The first focuses 
on the implementation of the decisions and the second focuses on the making the 
decisions (Regnier and MacKenzie 2017). In both exercises, the participants include 
emergency operations personnel and key decisions makers (Marine Colonels, and 
Eieutenant Colonels, and their civilian equivalents) that would be involved in the real-life 
hurricane preparation operations. Using the HDS with these exercises has produced 
favorable results, and the individuals benefited and gained considerable experience they 
could not have gained elsewhere except through decades of real life tropical storms 
(Regnier and MacKenzie 2017). 

The overall goal of each simulation is to help individuals and groups learn how to 
interpret the forecasts and their uncertainty, and then learn how to apply and use the 
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forecasts to make better decisions. Since one iteration of the simulation takes 
approximately 10 minutes, individuals can experience numerous TCs in a relatively short 
period of time. By progressing through multiple simulations, the user can gain valuable 
information, understanding, and practice making decisions in hurricane preparation 
operations. 

Due to the success of using the HDS in these exercises, MARFORRES requested 
additional support in developing region or command-specific versions of the HDS in an 
effort to educate and help prepare their smaller commands and facilities for hurricane 
preparations operations. Other organizations, such as the Federal Emergency 
Management Agency Region 6 and the United States Army Corps of Engineers in New 
Orleans have shown interest in the continued development and use of the HDS (Jose 
Garcia, Emergency Operation Manager at MARFORRES, personal communication, 
December 13, 2016). 

C. PROBLEM STATEMENT 

The MARFORRES HDS is not suitable for use by the MFRHTC in Hialeah, 
Florida or any other MFRHTC other than MARFORRES in New Orleans. The HDS is a 
static model that cannot adapt to any environment. New Orleans is a different location than 
Miami and has different topographical, environmental, and weather concerns. Though both 
cities have emergency management offices that coordinate activities, they operate 
differently due to the locations and unique perspectives. The units are significantly 
different. MARFORRES headquarters in New Orleans is a huge headquarters with over 
3000 civilians and military personnel while the MFRHTC in Hialeah is small with only a 
handful of full time military personnel (Colonel Jonathon Price, Commander of the 
MFRHTC, personal communication, January 11, 2017). The MFRHTC in Hialeah requires 
their own unique HDS where their unit’s decision, actions, and hurricane preparation 
operations can be applied so that they can gain valuable experience in hurricane decision 
making prior to an actual storm. In order to develop the HDS, the DBSS must be designed 
and created. The DBSS must contain the unique information, decision, actions, and 
hurricane preparation operations for the MFRHTC in Hialeah. 
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II. LITERATURE REVIEW 


This chapter, reviews and analyzes to the current knowledge base for making 
decisions in hurricane preparation operations. 

A. HURRICANE ORGANIZATIONS 

Worldwide, there are several TC centers that study, predict, monitor, and track 
TCs around the world, displayed in Figure 4. These organizations aim to mitigate the loss 
of life and damage to property from TCs by providing forecasts to governments and 
people in their respective regions. This thesis will focus on Region 1, specifically the 
NHC located in Miami, Florida. Other organizations or sub-organization of the NHC 
include: National Oceanic & Atmospheric Administration, National Weather Service, 
National Centers for Environmental Protection, Atlantic Oceanographic & 
Meteorological Laboratory, the Technology and Science Branch, and the Hurricane 
Researeh Division. 


WMO/ESCAP Panel ESCAP/WMO RAIV Hurricane 

on Tropical Cyclones Typhoon Committee Committee 



Figure 4. Worldwide TC Regions. Source: National Hurricane Center (2017c). 
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1 . 


National Hurricane Center 


The NHC issues real-time watches, warning, forecasts, and analysis of tropical 
storms in text and graphics as storms develop in the Atlantic and Eastern Pacific Oceans. 
These texts and graphics were used in the development of the HDS. 

The NHC’s Technology and Science Branch develops, tests, and integrates new 
and existing technologies and tools into tropical weather predictions models. The 
Technology and Science Branch uses several models (statistical and dynamical) that are 
used for forecasting and predicting TC behavior and the associated weather conditions 
(such as storm surge, wind, rainfall). The Technology and Science Branch assisted the 
Naval Research Laboratory in the development of the Automated Tropical Cyclone 
Forecasting System (ATCF), a computer web-based application, which integrates various 
information and models to automate and optimize portions of the TC forecasting process 
(National Hurricane Center 2017d). 

The ATCF is used by TC forecasters for situational awareness and understanding, 
training, and research. Sampson and Schrader (2000) indicated that it allows forecasters 
to consolidate forecasts, generates the consensus (average) track, and lets forecasters 
place forecasts. It lets forecasters easily generate messages, and issue warning and 
advisories for areas in the TC’s projected path. The system also stores past TC data for 
users to review and study. The system allows coordination and sharing of TC data and 
information between multiple agencies in a near real-time common framework, which 
enables decision makers across agencies to make informed decisions (Naval Research 
Laboratory 2010). Several pictures are displayed in Figure 5 and Figure 6 of the ATCF 
user interface using Hurricane Irene as an example. In the figures, the “Objective Aids” 
tool box allows the user to select the center of the forecasts, date, time, the specific model 
forecast, and then display the fields in the graphic. 
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Figure 5. The ATCF User Interface of Hurricane Irene with the Official NHC 
Model Forecast Over a Multiple Day Period. Source: Naval Research 

Laboratory (2010). 



Figure 6. The ATCF User Interface of Hurricane Irene with Various Model 
Forecasts for a Specific Period. Source: Naval Research Laboratory 

( 2010 ). 


Though the ATCF is a useful automated tool, it does not replace the expertise and 
judgment of human forecasters in making decisions in TC preparation operations. 
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2. Miami-Dade County Office of Emergency Management 

Miami-Dade County is located in the southeast corner of Florida and is home to 
the MFRHTC; therefore, it is the emergency management office relevant to this thesis. 
The city of Hialeah has an emergency management office but the MDOEM’s actions 
have a bigger impact on the MFRHTC in large part because the county’s evacuations 
substantially affect the times required for the MRFHTC to evacuate and complete other 
actions. The MDOEM operates much like a military tactical or joint operation center, 
with the exception that it is only used in the event of an emergency that threatens the 
entire county. The MDOEM maintains a comprehensive emergency management plan 
designed to address a variety of possible threats to the county, its citizens, and businesses. 
The essential purpose of the comprehensive emergency management plan and MDOEM 
is to provide a structured and coordinated system for preparedness, response, and 
recovery for the county. During an emergency, the MDOEM is the central hub of 
information, action, and news for the county. The magnitude of the event determines the 
scale at which the MDOEM is used. The comprehensive emergency management plan is 
divided into several sections: situations and assumptions, concept of operations, 
responsibilities, and preparedness. 

Tropical cyclones are the greatest threat to the county and their activity is 
continuously monitored by the MDOEM. When a TC develops in the Caribbean Sea, 
Atlantic Ocean, or Gulf of Mexico, the MDOEM monitors the storm, its forecasted track, 
and intensity. As the TC develops, moves toward Elorida, and increases in intensity 
(especially to hurricane status) the MDOEM prepares for the potential impacts. In order 
to help the MDOEM make decisions, they have developed six hurricane protective action 
decision making guides with evacuation clearance times. These guides assist the 
MEOEM in issuing warnings and evacuations by using the forecasted wind cone 
probability forecasts, wind speed, time to landfall, probability of increasing winds, 
probability of storm surge, impact to the evacuation zones, inland flooding hazards, and 
category of hurricane. Attached within the guides are the calculated clearance times to 
evacuate each of the evacuations zones. Eigure 7 displays the evacuation zones, where 
the teardrop depicts the MERHTC’s location. Additionally, the MEOEM uses a public 
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storm-surge simulator developed by Florida International University that predicts the 
potential level of water at specific locations based on the category of hurricane. Graphics 
for each level of hurricane can be found on the National Hurricane Center website. Figure 
8 displays the predicted storm surge (water level) at the MFRHTC location for a category 
5 hurricane, where the teardrop depicts the MFRHTC’s location. From the evacuation 
zone planning map and the storm surge simulations, one can see that the MFRHTC is not 
in any of the evacuation zones nor any of the predicted storm surge areas, but this does 
not mean that it will not receive any flooding. The evacuation zone maps and storm surge 
simulations do not account for rainfall, which accompanied with storm surge and wind 
could cause substantial flooding at the MFRHTC’s location. 

The MEOEM has gone through extensive planning and preparation for a 
hurricane strike. The comprehensive emergency management plan, protective action 
decision making guides, storm surge simulator, and established evacuation zones are all 
useful tools, but ultimately humans (decision makers) must always be in the loop and are 
responsible for mitigating the loss of life and damage in the event of a hurricane strike. 
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Figure 7. Storm Surge Evacuation Planning Map. Adapted from Miami-Dade 

County (2013). 
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III. METHODOLOGY 


This chapter describes how a system engineering (SE) framework can be applied 
to develop future HDSs and the methods, purpose, and type of data and information 
eolleeted in this thesis. It explains how SE, the U.S. Army design methodology, and the 
military decision making process (MDMP) eombine together to form the mission 
engineering (ME) analysis process. Evaluating hurricane preparation operations through a 
ME analysis approach shapes what the DBSS is and helps understand the information and 
resourees required for the creation of a mission plan. 

A. APPLYING A SYSTEM ENGINEERING FRAMEWORK TO DEVELOP 
FUTURE HDSS 

1. System Engineering 

The International Council of Systems Engineering, defines SE as: 

An interdiseiplinary approaeh and means to enable the realization of 
successful systems. It focuses on defining customer needs and required 
functionality early in the development cycle, documenting requirements, 
then proceeding with design synthesis and system validation while 
considering the complete problem. (International Council of Systems 
Engineering 1998) 

Through SE, various disciplines and speeialty groups are integrated to perform a 
struetured system or produet developmental proeess. This process begins with a eustomer 
needs analysis and definition of problem. It progresses through production, operation, and 
eventual retirement of a system. SE considers both the technical and business needs of all 
the stakeholders and customers with the goal of providing the customer or user with a 
quality product or process (International Council of Systems Engineering, 1998). Systems 
engineering established the process (mission plan in ME) as well as ereates the product 
(mission in ME and the DBSS for the HDS in this thesis). 

2. Systems Engineering Process 

The SE proeess starts with a eustomer needs analysis and ends with an output 
(produet or process). The SE methodology eonsists of seven basic steps or functions in 
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between, which are detailed in the International Council of Systems Engineering SE 
process in Eigure 9. The steps in the process are not performed in sequence, rather they 
are performed in an iterative and parallel manner. The SE process can be applied 
throughout the entire process of developing the HDS. An SE approach is instrumental in 
creating a conceptual design for the DBSS that will be used for future HDS versions. 



Eigure 9. The International Council of Systems Engineering Systems 

Engineering Process. Adapted from International Council of Systems 

Engineering (1998). 

3. Waterfall Process Model 

The waterfall process model (depicted in Eigure 10) is one of many process 
models used in SE. The process model was designed for software engineering and fits 
best with the design and development of the HDS. The waterfall process model is a 
sequential design model in which progress flows steadily downwards (like a waterfall) 
through the typically applied steps listed in Eigure 10. The primary advantages of the 
waterfall model include: departmentalization and control with no overlapping steps and a 
well-established schedule with milestones, deadlines for each step, and an iterative feed 
process that enables refinement. 
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Figure 10. Waterfall Proeess Model. Adapted from Blanehard and Fabryeky 

( 2011 ). 

The MARFORRES HDS eomprised one iteration of the waterfall model and the 
Hialeah HDS is eurrently in the design step of the seeond iteration. 

4. The Product Life-Cycle of the HDS 

The HDS produet life-eyele (depieted in Figure 11) ean be divided into four 
eoneurrent phases arranged in parallel. The aequisition phase includes: conceptual and 
preliminary designs, detailed design and development, production and construction. The 
utilization phase includes: product use, support, phase-out, and disposal. Version one of 
the HDS is in the utilization phase while version two is in the production and 
construction phase. Though all of the phases and steps in the HDS’s life cycle are 
important, this thesis will focus on developing a conceptual design for the DBSS future 
HDSs so that MARFORRES can develop HDS versions for other MERHTCs. Individual 
tailored HDSs will help train the commanders, staffs, and personnel at the smaller unit 
headquarters so they will be better equipped to make decision when threatened with TCs 


21 



and hurricanes. The tailored HDSs each require a DBSS with unique information, 
decisions, actions, and hurricane preparation operations to their location and unit. The 
conceptual design that will be detailed in Chapter V is essential to creating functional 
DSSs. 


N 

E 

E 

D 


ACQUISITION PHASE 


Conceptual/ 

Detail 

Production 

Preliminary 

Design and 

and/or 

Design 

Development 

Construction 


■UTILIZATION PHASE—*4 


Product Use, Support, 
Phase-out, and Disposal 



Figure 11. 


The Product Life-Cycle Phases. Source: Blanchard and Fabrycky 

( 2011 ). 


In turn, the product life cycle phases can be related to the waterfall model in 
Figure 10: 

• customer need, conceptual and preliminary designs analysis, 
requirements specifications, and a little into the design step 

• detailed design and development design 

• production and construction implementation, testing, and integration 

• products use, support, phase-out, and disposal operation and 
maintenance 

The product life-cycle phases can be related to the MDMP in Figure 13: 

• customer need step 1 (receipt of mission) 

• conceptual and preliminary designs steps 2-3 (mission analysis and 
CO A development) 

• detailed design and development steps 4-6 (COA analysis, comparison, 
and approval) 

• production and construction step 7 (orders production) 

• products use, support, phase-out, and disposal OPORD execution 
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Understanding the customer need leads to the developing the conceptual design. 
Developing a conceptual design for the DBSS for future HDSs is the first step in the 
design and development process. A conceptual design consists of the following: 

• defining the problem and needs identification 

• planning and architecting the system for the needs identified 

• conducting a system feasibility analysis 

• defining and developing the system’s operational requirements 

• defining a concept for the system’s maintenance and support requirements 

• identifying, establishing, and prioritizing technical performance measures 

• conducting a functional analysis and allocating requirements to 
components and systems 

• conducting a system trade-off analysis 

• conducting a conceptual design review and implementing changes if 
needed (Blanchard and Fabrycky 2011) 

B. MISSION ENGINEERING AND THE MILITARY DECISION MAKING 
PROCESS 

I. Mission Engineering 

Mission engineering is defined by the Office of the Deputy Assistant Secretary of 
Defense for Systems Engineering as the “deliberate planning, analyzing, organizing, and 
integrating of current and emerging operational and system capabilities to achieve desired 
warfighting mission effects” (Gold 2016, 3). Mission engineering will be used to examine 
how the HDS and DBSS can be used by the MFRHTC in Hialeah. It will define the 
mission of the HDS, determine the information and resources requirements of the DBSS, 
and help develop a plan to integrate the HDS into the MFRHTC capabilities. The ME 
process (displayed in Figure 12) is circular and requires all three parts to work in 
conjunction with each other to perform successfully. It starts with systems acquisition, 
transitions to mission, system of system (SoS) architecture, and engineering, then moves 
to operations, which returns to systems acquisition. 
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Figure 12. Mission Engineering Process. Adapted from Gold (2016). 


In ME, the mission and mission plan are the “system.” The mission consists of the 
“who,” “what,” “when,” “where,” and “why,” and the mission plan is the “how.” The 
HDS used the waterfall process model (discussed earlier in this chapter) as a means to 
accomplish the mission. The waterfall process model is the link (double arrows) between 
the mission, SoS architecture, and engineering and operations in ME. Mission 
engineering explores and addresses the tradeoffs at multiple levels between individual 
systems, components, and the data exchanges among the systems and components over 
the entire mission and system (Gold 2016). Throughout the ME process, SE is applied to 
support the operational mission objectives. Mission engineering is instituted in the design 
and development of the HDS in the following ways: 

• enables the mission outcomes to be defined to identify and frame the 
problem 

• establishes mission success factors and performance requirements for 
individual components and systems 

• aligns the mission, current state, and desired end state with all of the 
stakeholders 

• creates a single framework to analyze the mission 

• develops assessment frameworks which can be used to measure progress 
through the end-to-end mission execution and completion (includes 
system integration with other system, test and evaluation, and exploring 
mission threads) (Gold 2016) 
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2. The Military Decision-Making Process 

The Military Decision-Making Process (MDMP) is defined by the Center for 
Army Lessons Learned as: 

An iterative planning methodology that integrates the activities of the 
commander, staff, subordinate headquarters, and other partners to 
understand the situation and mission, develop and compare courses of 
action (COAs), decide on a COA that best accomplishes the mission, and 
produce an operation plan or order for execution. The MDMP helps 
leaders apply thoroughness, clarity, sound judgment, logic, and 
professional knowledge to understand situations, develop options to solve 
problems, and reach decisions. The MDMP is a process that helps 
commanders, staffs, and others think critically and creatively while 
planning. (Center of Army Lessons Learned 2015, 7) 

The MDMP process helps all stakeholders by laying out a framework to solve 
problems and plan complex operations. Figure 13 depicts the MDMP process, with the 
steps listed in the center, and each step’s inputs on the left and outputs on the right. 
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^ Key inputs ^ 

r Steps j 

X Key outputs ^ 

• Higher headquarters' plan or order 
or a new misston antiapated by the 
cxmmander 

Step 1: 

Receipt of Mission 

• Commander's initial guidance 

• Initial allocation of time 


• Higher headquarters' plan or order 

• Higher headquarters' knowledge 
and intelligefice products 

• Knowledge products from other 
organizations 

• Design concept (if developed) 

Warning order | | 

step 2. 

Mission Analysis 

• Mission statement 

• Initial commander's intent 

’ Initial planning guidance 

• Initial CCIRs and EEFIs 

• Updated IPB and running estimates 

• Assumptions 

1 a • • • ■ 


Warning order | 

• Mission statement 

• Initial corruTvander's intent, planning 
guidance. CCIRs. and EEFIs 

• Updated IPB and njnning estimates 

• Assumptions 

Step 3: 

Course of Action 
(COA) 

Development 

• COA statements and sketches 

■ Tentative task organization 

• Broad concept of operations 

• Revised planning guidance 

• Updated assumptions 

' Updated running estimates 

• Revised planning guidance 

• COA statements and sketches 

• Updated assumptions 

Step 4 

COA Analysis 
(War Game) 

• Refined COAs 

> Potential decision points 

• War-game results 

• Initial assessment measures 

• Updated assumptions 

• Updated running estimates 

• Refined COAs 

• Evaluation cntena 

• War-game results 

■ Updated assumptions 

Step 5 

COA Comparison 

> Evaluated COAs 

• Recommended COAs 

■ Updated running estimates 

* Updated assumptions 

• Updated running estimates 

• Evaluated COAs 

• Recommended COA 

■ Updated assumptions 

Step 6; 

COA Approval 

• Commander-selected COA and any 
modifications 

• Refined commander's intent. 

CCIRs. and EEFIs 

• Updated assumptions 


• Commander-selected COA with 
any modifications 

• Refined commander s intent. 

CCIRs, and EEFIs 

• Updated assumptions 


Step?; 

Orders Production 

• Approved operation plan or order 

CCIR corrwnander's cntical information requirement EEFi essential element of frwndly infformatKXi 

COA course of action IP8 inte<i«9eoce preparation of the battlefield 


Figure 13. Military Decision-Making Process. Source: Center of Army Lessons 

Learned (2015). 
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The waterfall process model, Figure 10, relates to both ME and the MDMP. In 
ME, Eigure 12, it is the double arrow that links mission, system of systems, architecture, 
and engineering to operations. In the MDMP, Eigure 13, the waterfall process model is 
associated with all the steps in the process: 

• analysis and requirements specifications steps 1-2 (receipt of mission 
and mission analysis) 

• design steps 3-6 (Course of Action (COA) development, analysis, 
comparison, and approval) 

• implementation, testing and integration, operation and maintenance 
step 7 (orders production and operations) 

During mission analysis step, the U.S. Army design methodology (depicted in 
Eigure 14) is applied. The methodology allows individuals and groups to apply “critical 
and creative thinking to assist in understanding, visualizing, and describing” a problem 
and the possible solutions or approaches to solving the problem (Center of Army Eessons 
Eearned 2015, 3). The methodology is especially useful in aiding conceptual design, 
initial planning, and outlines further detailed planning, which is normally connected with 
the MDMP in producing an operations order (OPORD). While developing future HDSs 
for new locations, the methodology can be applied to the conceptual and preliminary 
designs. The methodology begins by first framing an operational environment by 
describing the current state and the desired end state. It continues by framing the problem 
and describing the obstacles that stand in front of the desired end state. It continues by 
developing an operational approach to solve the problem and describing the decision and 
actions that could resolve the problem. This leads to the development of a plan, in which 
the MDMP is used. 
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Figure 14. U.S. Army Design Methodology. Adapted from Center of Army 

Lessons Learned (2015). 


The key outputs listed in the mission analysis step of the MDMP, Figure 13, and 
the results of the U.S. Army design methodology, Figure 14, are the same: a problem or 
mission statement, understanding of and the initial commander’s intent and planning 
guidance, and an operational approach (updated initial preparation of the battlefield and 
running estimates) that serve as the links between conceptual and detail planning (COA 
development). At the conclusion of the MDMP an OPORD is produced, which outlines 
the specifics on how and why the mission will be accomplished. The OPORD is the 
mission plan with the HDS as the mission. Though this thesis will not produce an 
OPORD, the thought process behind the OPORD, MDMP, and U.S. Army design 
methodology must be considered because the customer is a military unit and practices the 
MDMP. The MDMP is the mission, SoS architecture, and engineering box in ME, as 
seen in Figure 12. The OPORD is the mission plan, which is executed in the operations 
box in ME in Eigure 12. 

C. DATA COLLECTION 

This thesis uses two primary data resources and two case studies. The two data 
resources are: MAREORRES in New Orleans and the MERHTC in Hialeah, Elorida. The 
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case studies include the MARFORRES HDS (version one) and the Hialeah HDS (version 
two). 


1. MARFORRES Operations and Decision Making Processes 

MARFORRES is the U.S. Marine Corps Forces Reserve Headquarters in New 
Orleans which commands all U.S. Marine Reserve forces. MARFORRES is responsible 
for augmenting, reinforcing, and providing operational tempo relief to the active Marine 
forces in times of war, national emergencies, contingency operations, and peacetime 
(MARFORRES Commander 2016). MARFORRES must manage operations and 
personnel on missions throughout the county and in various parts of the world and cannot 
afford to shut down operations or lose contact with its subordinate units or personnel. 
Therefore, it is important for MARFORRES to track and monitor TCs that have the 
potential to effect operations and possibly force an evacuation. Data and information 
were collected during a site visit to MARFORRES from 12-14 December, 2016 when 
several meetings were conducted with the staff. It was essential to visit MARFORRES 
before visiting the MFRHTC in Hialeah to get an understanding of why the HDS was 
created, how the HDS is used, and figure out the future project scope and vision. During 
the site visit, data and information were collected to: 

• understand why the HDS was created and how MARFORRES uses it 

• gain insight into how MARFORRES helps MFRHTC in Hialeah 

• figure out how the emergency operations center at MARFORRES deals 
with TCs 

• determine the reporting requirements for the MFRHTC in Hialeah during 
a TC; and 

• determine the HDS version 2 (for Hialeah) project scope and timeline. 

2. MFRHTC Operations and Decision Making Processes 

The MFRHTC is a local command headquarters for Marine Corps Forces Reserve 
in Florida. The headquarters is responsible for coordinating and managing the training, 
support, facility usage, and deployments of Marine Reserve forces assigned to it. The 
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MFRHTC has individuals deployed to various parts of the world and cannot afford to 
shut down operations or lose contact with their deployed personnel, and therefore must 
track and monitor TCs that have the potential to affect operations and possibly force an 
evacuation. Visiting the MFRHTC in Hialeah was important to get an understanding of 
the unit, its operations, facilities, and personnel. Data and information was collected 
during a visit from 10-12 January, 2017 where several meetings were conducted with the 
unit’s staff and commander. During the site visit data and information were collected to: 

• understand the current TC preparation procedures and operations 

• learn how the unit tracks and monitors TCs 

• determine the decisions and actions the MFRHTC must take in preparation 
for a TC, their costs, and how they relate to the HDS 

• determine how the unit will use the HDS; and 

• define the reporting requirements for the MFRHTC in Hialeah during a 
TC. 

3. Versions One and Two of HDS 

This thesis uses the MARFORRES HDS as an exploratory and descriptive case 
study. Exploratory case studies are used to present data, information, and descriptions of 
an event, project, or investigation. Descriptive case studies present data and information 
on an event, project, or research so that new data and information can be compared to 
pre-existing theory, data, and information. The Hialeah HDS is used as an exploratory 
case study. 

When evaluating both the MAREORRES and Hialeah HDSs, this author seeks to 
understand the data and information: why it was created, how it was constructed, how it 
will it be used, how it will operate, and how each decision will be made or accomplished. 
Additionally, the evaluation will seek to discover any improvements or changes that 
would benefit future HDS versions. To accomplish this, a functional analysis approach 
using ICOM (inputs, controls and constraints, outputs, and mechanisms) charts, detailed 
in Eigure 15, will be used. During this approach, both the HDS as a whole and key 
decisions will be evaluated separately. 
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Controls / Constraints 


• Technical 

• Political 

• Sociological 

• Economic 

• Environmental 



Inputs 


System Requirements 
Organizational Structure 
Raw Materials 
Data/Documentation 



System 


• Human Resources 

• Material/Liquids 

• Computer Resources 

• Facilities/Utilities 

• Maintenance and 
Support 



Mechanisms 


• Mission Plan 

• System/Product Ready 
for Customer Use 

• Supporting Resources 

• Waste (reside) 



Outputs 


Figure 15. ICOM Chart for a Functional Analysis Process. Adapted from 

Blanchard and Fabrycky (2011). 


The functional analysis will be used to breakdown the HDS into its components 
and functions. The functional analysis is a process where system requirements are 
translated in design criteria and then the resources required are identified for system 
operation and support. This process includes breaking the system level requirements 
down in sub-system requirements and further down as far as the hierarchical structure is 
required to identify the input design criteria (Blanchard and Fabrycky 2011). Breaking 
down the HDS in a functional hierarchy helps define the bases for functional analysis and 
displays the system architecture. Though this is useful in breaking the systems into 
smaller more manageable parts it lacks the ability to indicate the flow of functions and 
sub-functions in time and space. A functional flow block diagram (FFBD) satisfies this 
limitation and provides an understanding of the overall operational process in a logical, 
sequential order. 

This chapter discussed the methodology of how this thesis was conducted. It 
defined systems engineering, the systems engineering process, and how they will be used 
to evaluate the HDS. It defined how ME will be used to examine what the HDS requires. 
It described the waterfall process model and how it related to the HDS, mission 
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engineering, and the military decision making process. It described the HDS product life- 
cycle phases and how they fit into the waterfall model and the military decision making 
process. It described mission engineering, the military decision-making process, the army 
design methodology, how they fit together into each other and the HDS, and how they are 
mutually supportive of one another. It described how a system engineering framework 
can be applied to develop a DBSS for future versions of the HDS. It summarized the data 
collection methods and how a functional analysis approach will be used to evaluate the 
HDS as the system and the key decisions. Lastly, it detailed the steps to create a 
conceptual design for a database support system for future HDSs. The following chapter 
will discuss the results of the thesis research detailed in this chapter. 
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IV. DATA ANALYSIS AND RESULTS 


This chapter relates how the methodologies described in Chapter III are used to 
examine the problem. It also details the data and results. It describes how version two of 
the HDS can be decomposed into its components, how the components fit together and 
interact with each other, and the differences between the version one and two of HDS. It 
identifies the type of information and resources necessary for hurricane preparation 
operations and the key decisions that the commander can make for the MFRHTC in 
Hialeah. It describes how SE, ME, the MDMP are applied and used to analyze the 
decision-making process. 

A. DECOMPOSITION OF THE HDS AND DBSS 

I. Applying the SE Process and U.S. Army Design Methodology to the 
HDSs 

In order to transform from a static database (version one of the HDS) to a 
dynamic database (version two of the HDS), it is important to understand the differences 
between the two versions, what the components of the HDS are, how they fit together and 
interact with each other, and to identify the information that the HDS requires. To do this, 
the SE process, concepts, and the U.S. Army design methodology will be used, all 
described in Chapter III. 

In the SE process, the problem must first be stated. In the U.S. design 
methodology, the operational environment must be framed, with both current and desired 
end states identified. This can best be done by describing the differences between version 
one and two of the HDSs. Version one of the HDS was specific to MAREORRES in New 
Orleans. In version one, the information required to construct the HDS and DBSS was 
hard coded into the programming code and no spreadsheet existed. Because version one 
of the HDS was successful and accomplished its objectives, MAREORRES requested 
that additional HDSs be developed for their reserve training facilities located along the 
Gulf of Mexico, Caribbean Sea, and South Atlantic coast. Version one of the HDS was 
designed specifically for MAREORRES and the New Orleans area and was not designed 
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to be adaptable to different locations; therefore, it had to be redesigned. This was 
primarily due to the information collected being hard coded into the programming, which 
would have required significant time and effort to input new information into the code 
line by line. The HDS needed a way to transform from its current version into a version 
that would enable it to be adapted to new locations. 

The solution was to develop a DBSS that would store the information in which 
the programming code would reference for the data when needed. This would require 
rewriting the programming code and developing a storage mechanism for the 
information. To make it easier to develop version two of the HDS, spreadsheets were 
created to allow information to be changed quickly without having to change the 
programming code. Figure 16 illustrates the components of version two of the HDS (end 
state). The arrows represent the flow of information and the circles represent interaction 
points between different components. The circles represent interaction points where the 
information from the user interface, programming code, user inputs, and DBSS 
(spreadsheets) interact. The current state of the HDS is illustrated in Figure 16 minus the 
spreadsheets. 



Figure 16. Schematic of the Current State of the HDS and Its Components 
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Version two of the HDS has four primary components: user interface, 
programming code, simulated TCs, and the DBSS. The user interface is what the user 
sees on the screen and interacts with. It was described in Chapter I, Section B.1.3, and is 
displayed in Figure 2 and the Appendix. For version one, Regnier and MacKenzie 
designed the simulation and built it in Matlab. CED3 designed the online user interface, 
built it in Java, pulling from data files generated by running the Matlab code repeatedly to 
implement the decision logic. For version two, CED3 coded the logic shown in Eigure 16 
directly so that the information contained in the easily understood spreadsheets can be 
turned into a fully functional simulator. The user interface is very similar in version two. 

The simulated TCs consist of storm data that is presented to the user as updated 
TC forecasts, surge data, winds data, and the time associated with each. Each version of 
the HDS will have a set of TCs that were designed to represent plausible TCs for the 
location. The DBSS is primarily composed of nine spreadsheets that contain the 
information collected from the unit. 

Next in the SE process is investigating alternatives and modeling the system. In 
the U.S. Army design methodology, this is developing an operational approach and 
determining what will resolve the problem. Two alternatives were analyzed: the current 
design of hard coding the information into the programming or the creating of nine 
spreadsheets into a DBSS and shifting to a Java only programming language. The 
spreadsheets were selected because they allowed for an easier transition of information 
between versions. 

Integration is the next step in the SE process and developing a plan in the U.S. 
Army design methodology. This is the task that links the mission, SoS, architecture, and 
engineering block in ME to operations. Additionally, it is the COA development, 
analysis, comparison, and approval in the MDMP. Here, the tasks and steps required to 
develop the new DBSS for version two of the HDS were identified and the development 
team began work to complete them in the specified time. During this step, the 
information that the DBSS requires to take actions and make decision were determined 
and site visits to both MAREORRES and the HTC in Hialeah were conducted to gather 
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this information. This step is currently underway and the DBSS is being developed and 
integrated into the HDS. 

The next steps in both processes are to launch the system, assess performance, 
and re-evaluate. These steps are set for the HDS version two launched in late fiscal year 
2017 as the components of the HDS are finished, integrated, the system is tested, and 
packaged for release to the customer. 

2. Information Requirements of the DBSS 

The DBSS consists of nine spreadsheets. These spreadsheets include: decisions, 
actions, decision timing, decision costs, winds, surge, decision storm, decision 
announcements, and announcements. The spreadsheets are displayed in the supplemental 
material. Systems engineering and the MDMP were used to determine, collect, refine, 
and verify what information the spreadsheet required. 

The decisions spreadsheet contains the key decisions that the user is prompted to 
make in the HDS. When the user selects a decision, the time is recorded and information 
is sent to five interaction points. Depending on the time the user makes the decision and 
the position of the TC, announcements and popups may be triggered. The key decisions 
are detailed in the following section of this chapter. 

The actions spreadsheet contains all the actions the MFRHTC must complete 
when a decision is made. The time and actions are recorded in the record of events and 
displayed in the feedback at the end of the simulation. 

The decision timing spreadsheet specifies the conditions, announcement, and 
results in the event a decision is made too soon after an earlier decision. If a decision is 
made and the specified time has not elapsed, a pop up is triggered letting the user know 
the results of the decision at that time. The events are listed in the feedback at the end of 
the simulation. 

The decision costs spreadsheet details the fixed and variable cost of making each 
decision. Fixed costs are a one-time cost while variable costs are dependent on the wind 
speed and surge, which affect the duration of some activities such as an evacuation. 
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The winds and surge spreadsheets specify the wind and surge thresholds with 
their associated decisions the MDOEM would make and other consequences. If the 
threshold is reached, the event is listed in the feedback at the end of the simulation. 

The decision announcements spreadsheet describes the announcements that pop 
as a result of the time when the user selects decisions in relation to announcements. For 
example, these describe any conflicts with local state, county, and MDOEM operations. 

The decision storm spreadsheet describes the consequences of the time the user 
makes decisions in relation to the surge and winds conditions at the time. The events are 
listed in the feedback at the end of the simulation. 

The announcements spreadsheet details announcements that pop up if the TC 
meets specified conditions based on wind cone probability, probability of wind speed, 
probability of surge level, and the expected TC time to landfall. If the specific condition 
is met, the time is recorded in the record of events, a pop up event is displayed and then is 
listed in the feedback at the end of the simulation. For example, announcements may 
describe actions by the MDOEM, or TC events like hurricane-force winds in Miami. 

3. Function and Component Decomposition of the HDS Leading to the 
BBSS Conceptual Design 

Figure 17 illustrates the functional hierarchy of the HDS. The functional hierarchy 
displays the HDS’s functional architecture, defining the “whats” that the HDS must do 
and organized the functions into sub-systems in a top-down, highest to lowest logical 
order. The HDS functional hierarchy is illustrated to point to the location specific 
information storage system, or DBSS (the highlighted section in the red box). This 
system is required to enable to HDS to transform so that it can be tailored to new 
locations. A functional hierarchy is defined for the DBSS in Chapter V. 
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Figure 17. Functional Hierarchy of the HDS 


Figure 18 illustrates a FFBD for creating a HDS. In the design and create the 
HDS components steps (the highlighted section in the red box) the DBSS is identified, 
detailed, and constructed. An FFBD for creating the DBSS is defined in Chapter V. 



Figure 18. FFBD for Creating an HDS 


Figure 19 illustrates a physical block diagram of the HDS components. In the 
figure the components of the HDS can be seen, where the DBSS is highlighted in the red 
box. Chapter V details a physical flow block diagram of the DBSS components. 
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Figure 19. Physical Block Diagram of the HDS 


B. ANALYSIS OF THE KEY DECISIONS AND LOGIC OF THE HDS 

I. Key Decisions and Functional ICOM Analysis 

The decisions offered within the Hialeah HDS are based on how the staff and 
commander of the MFRHTC in Hialeah constructed their process for dealing with 
hurricane planning and preparations. During this process, they identified seven key 
decisions with associated actions for each section that they are required to complete. The 
decisions begin approximately 120 hours prior to a TCs projected time to landfall. 
Additionally, the staff broke hurricane preparations operations into four phases. The 
phases (with respective time windows) and decisions include: 
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Phase 1: Pre-preparation Readiness (120 hours -i-) 

Phase 2: ADVON Preparation (120 - 72 hours) 

Decision 1: Prepare the ADVON party 

Phase 3: Storm Proofing and ADVON / RBE Deployment (96 - 24 hours) 

Decision 2: Storm proof the HTC and personal property 

Decision 3A: Deploy the ADVON party to the alternate command and 
control location and authorize a voluntary evacuation 

Decision 3B: Prepare and standup the RBE 

Phase 4: Evacuation / Shelter in Place (24 - 0 hours) 

Decision 4A: Secure the HTC and issue a mandatory evacuation order 

Decision 4B: Shelter in place 

Decision 5: Transfer command and control to the alternate headquarters 
During discussions with the staff and commander of the MERHTC in Hialeah 
decisions 2, 3A, and 3B could be made in any order. The ability to make these decisions 
in any order would have required a significant re-design of the current HDS 
programming and additional time to complete, therefore the order previously illustrated 
was established. 

Before analyzing each decision through a functional analysis ICOM approach the 
entire system must be analyzed. Eigure 20 displays the approach of how the inputs are 
transformed into the outputs. The controls and constraints guide the inputs while the 
mechanisms change the inputs. 
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Controls / Constraints 


Inputs 


Version Two HDS System 
Requirements 
Previous HDS Materials 
MARFORRES, MFRHTCin 
Hialeah, and Miami-Dade 
OEM Requirements 


Simulated TCs for Miami 
(NHC code) 



Version Two HDS 
Technical Design 
Limitations 
Budget 



Hurricane Decision 
Simulator (Version Two) 


NPS, CED3, 

MARFORRES, MFRHTC 
in Hialeah Personnel 
NHCTC Code 
Computer/Server 
Storage Space 
Maintenance and 
Support Capabilities 



Mechanisms 


Key Decision and Actions 
Required for Hurricane 
Preparations 
Version Two HDS 
Documentation 
Reach Back Support 
Capabilities from NPS 



Outputs 


Figure 20. Functional ICOM Analysis for Version Two of the HDS 

After determining what the key decisions are and analyzing the entire system 
though a functional analysis ICOM approach, the decisions can be analyzed individually 
through the same approach. Figure 21 illustrates an ICOM chart decision one, and Table 
4 documents the whole ICOM analysis process for each decision. 


Controls / Constraints 


• Tropical Cyclone 
Development 

• Unit Budget 

• Unit Operational Tempo 

• Miami-Dade OEM status 
and updates 



Inputs 


Tropical Cyclone Monitoring 
Initial List of ADVON 
Personnel, Vehicles, and 
Equipment 



Decision 1: Prepare ADVON 


Unit Personnel, Vehicles, 
Equipment, Fuel, Water, 
Food 



Mechanisms 


Updates Hurricane Status to 
Higher HQ 

Liaison with Florida Highway 
Patrol 

Verification of Primary and 
Alternate ADVON Routes 
Verification of Primary and 
Alternate HQ Locations 
Fueled Vehicles and Cans 
Contacted Civilian Wreckerfor 
Support 

Initial ADVON Communications 
Plan 

ADVON Cost Estimates and DTS 
Orders Productions 
Employment Lettersfor SMRC 
Drivers 

Funding Requests sent to 
Comptroller 
Established CCIRs 
Vehicles Loaded with all 
Equipment 

Lodging Coordinated at Primary 
HQ Location 

Issued Equipment to ADVON 
(including sensitive items) 
Consolidated Secret/Classified 
Documents 

Liaison with Primary HQArmory 


Outputs 



Figure 21. Functional ICOM Analysis of Decision 1: Prepare ADVON 
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Table 1. ICOM Chart for the MFRHTC HDS 


1 Inputs, Controls and Constraints, Outputs, and Mechanisms Chart for Hialeah MFRHTC 

Index 

Decision (time to 
complete) 

Inputs 

Controls / Constraints 

Mechanisms 

Outputs 

1 

Prepare ADVON (12 
hours to complete) 

Tropical cyclone monitoring 

Initial list of ADVON personnel, vehicles, 
and equipment 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Liason with Florida hughway partol for police escort of ADVON 

Determine and verify primary and secondary routes for ADVON 

Determine and verify primary and secondary alternate headquartes locations 

Fuel all vehicles and fuel cans 

Contract civilian wrecker support for disabled ADVON vehicles 

Initial ADVON comunications plan 

ADVON cost estimates and initial DTS orders production for personnel 

Weapons qualifications check for force protection personnel 

Employment letters for SMRC drivers 

Funding request sent to comptroller 

Review and establish CCIRs 

Load vehicles with ADVON gear, equipment, and containers 

Coordinate lodging for ADVON 

Issue ADVON weapons, ammo, sensitive items 

Liason with alternate headquarters locations armory for sensitive items storage 
Prepare communications equipment 

Consolidate secret/classified paperwork/data 

2 

Storm Proof the 

HTC and Personnel 

Property (24 hours 
for each) 

Tropical cyclone monitoring 

Identify vehicles and equipment not 
going on ADVON 

Identify inclement weather containers 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Update accountability and recall rosters 

Update unit communication pla and notify all personnel 

Coordinate force protetion plan and brief to personnel 

Ensure all debris cleaned up around HTC 

Inspection of all section's area to ensure storm proofing is complete 
Communicate entitlement to all personnel 

Personnel issued food, water, force protection gear 

Personnel storm proofed HTC and personnel Property 

Secure all vehicles and equipment that will be left ourdoors 

3A 

Deploy the ADVON 
and Authorize a 

Voluntary 
Evacuation (12 
hours) 

Tropical cyclone monitoring 

Primary and secondary routes for ADVON 
Primary and secondary alternate 
headquartes locations 

Approved list of ADVON personnel, 
vehicles, and equipment 

Final ADVON comunications plan 

Issued personnel DTS and MROWS 

Storm proof HTC and personnel property 
order 

Tropical cyclone development 
Budget 

Unit operational tempo 
Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Linkup with Florida hughway partol for police escort of ADVON 

Linkup with civilian wrecker support for disabled ADVON vehicles 

Authorized voluntary evacuation order issued 

OPSEC, convoy, and commanders birefs given to ADVON 

Vehicle and sensitive item checks 

Alert local police that all weapons and ammo have been moved 

Ensure WEX card is with ADVON 

ADVON deployed and voluntary evacuation authorized 

Update personnel accountability 

3B 

Prepare and 
Standup the RBE 
(12 hours) 

Tropical cyclone monitoring 

Updated personnel roster 

Finalized RBE veicles, equipment, and 
gear lists 

Storm proof HTC and personnel property 
order 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Conduct frost call 

Recall roster finalized 

All RBE personnel have weapons qualifications on file 

All HTC watch lists verified, finalized, and distributed to personnel 

Weapons, ammo, and all force protection gear issued to RBE 

Commanders safety brief issued 

Section OIC walkthough of areas 

Finalized travel orders for potential evacuation 

RBE stood up 

Food, water, and additional supplies for 1 week staged 

4A 

Secure the HTC and 

Issue a Mandatory 
Evacuation (2 
hours) 

Tropical cyclone monitoring 

Final recall roster 

Deploy ADVON order or prepare and 
standup RBE order 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Final HTC inspection conducted/walkthough 

HTC lockdown 

Personnel ordered to evacuate 

4B 

Secure the HTC and 

Shelter in Place (1 
hour) 

Tropical cyclone monitoring 

Final recall roster 

Deploy ADVON order or prepare and 
standup RBE order 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Final HTC inspection conducted/walkthough 

HTC lockdown 

Personnel ordered to shelter in place 

5 

Transfer Command 

and Control to the 

Alternate 

Headquarters (1 
hour) 

Tropical cyclone monitoring 

Deploy ADVON order 

Tropical cyclone development 
Budget 

Unit operational tempo 

Miami-Dade OEM status 

Personnel 

Vehicles 

Equipment 

Fuel 

Water 

Food 

Update hurricane status with higher headquarters 

Command and control temporatly transferred to alternate headquarters 


In this process, one can see that the inputs and outputs changed from decision to 
decision, but the controls, constraints, and mechanisms remain the same. 
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2 . 


Hialeah HDS Decision Logic 


The HDS requires decisions that have an order. The first preparation must be 
taken before progressing to the second and so forth. When the user makes a decision, it 
triggers follow on actions. If the user chooses to continue with the simulations and not 
take a preparation action (decision) at that time, then the simulation continues to the next 
forecast update and prompts the user for the same decision. The Hialeah HDS decision 
logic is displayed in Figure 22. The MARFORRES decision logic was displayed in 
Figure 3. The simulation then continues prompting the user for decisions until all of the 
preparation steps have been taken or the simulation is complete and the TC has 
dissipated. 
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Figure 22. Hialeah HDS Decision Logic. Adapted from Regnier and 

MacKenzie (2017). 


To better illustrate how the key decisions flow, a decision tree was created, 
displayed in Figure 23. The decision tree shows all the paths, outcomes, and relationships 
between the decisions that the user can make through the simulation. In the decision tree, 
it can be seen that if the user selects the “prepare & standup RBE” option then the 
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“deploy ADVON & authorize a voluntary evacuation” option cannot ever be selected, 
and vice versa. Choice at the third decision node splits the decision tree into two parallel 
branches, which is different from the HDS for MARFORRES. Additionally, the user is 
only offered the option to “transfer command and control (C2)” if they select the decision 
“deploy ADVON & authorize a voluntary evacuation.” Working backwards through the 
decision tree, one can see that all of the decisions have prerequisites, which the user must 
make in the simulation or they will not be prompted for the decision. 


Transfer9G2 



Figure 23. MFRHTC HDS Decision 

This chapter detailed how the methodology described in Chapter III was used to 
examine the problem and details the data and results. The results of the analysis include: 
a description and illustration of how the DBSS was created, the information it requires, 
its functions, components, and how it operates. The key decisions of the MFRHTC in 
Hialeah were analyzed through an ICOM process to determine how the inputs were 
guided by the controls and constraints and changed by the mechanisms into the outputs. 
Additionally, the Hialeah HDS logic was detailed along with the decision logic. The next 
chapter details the conceptual design process for the DBSS and an overall conceptual 
design so that future versions of the HDS can be developed for different locations. 
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V. CONCEPTUAL DESIGN FOR THE BBSS 


As stated earlier in Chapter III, developing a conceptual design for the system or 
product is the first and most important step in the design and development process. The 
conceptual system design develops the basis for understanding of the customer need and 
establishes the path forward. This chapter will detail a conceptual design for the DBSS so 
future HDSs can be developed for additional locations. Figure 24 illustrates the 
conceptual design process as defined by Blanchard and Fabrycky (2011). The steps in 
Figure 24 will be detailed in this chapter. 
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Figure 24. Conceptual System Design Steps. Adapted from Blanchard and 

Fabrycky (2011). 
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A. 


SYSTEM PLANNING AND ARCHITECTING 


System planning and architecting begin after a problem and need have been 
identified for a new or improved system and the system’s requirements have been 
identified. Figure 25 details the early system planning and architecting process in the 
conceptual design phase. The high-level system architecture contained in the system 
specification (Type A) forms the foundation for the lower-level architecture preparation 
and planning. The system specification (Type A) and the systems engineering 
management plan combine to establish the functional baseline or Milestone I for the 
project or system. Once Milestone I is reached, the program or system progress onto the 
preliminary design phase. 


Conceptual Design Phase 


Preliminary Design Phase 


Milestone I 
(Functional Baseline) 



System Specification 
(Type A) 


System Engineering 
Management Plan 
(SEMP) 






Program / System 



Implementation 




Figure 25. Early System Planning and Architecting. Adapted from Blanchard 

and Fabrycky (2011). 


After MARFORRES requested additional HDSs be built, all stakeholders for the 
meet, discussed, and defined the HDS system requirements and development timeline, to 
include the DBSS. Then the NPS team began to develop the system architecture and 
established a functional baseline. 
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B. DEFINING AND DEVELOPING THE DBSS’S OPERATIONAL 

REQUIREMENTS 

After an approach or alternative has been selected and a COA is approved, it is 
necessary to develop the operational requirements of the system. In developing the 
conceptual design, a systems engineering is used to evaluate commonly listed seven areas 
that define the DBSS’s operational requirements: 1) mission definition, 2) performance 
and physical parameters, 3) operational deployment or distribution, 4) operational life- 
cycle, 5) utilization requirements, 6) effectiveness factors, and 7) environmental factors 
as identified by Blanchard and Fabrycky (2011). 

1. Mission Definition 

What are the primary and secondary missions of the DBSS? What must the DBSS 
accomplish, and how does it accomplish it? The DSSs primary mission is to store and 
send information to the HDS during a simulation. Its secondary mission is to collect the 
information from the new location. The DBSS must be able to tell the user what 
information is required, receive the information from the user, check the information for 
completeness and correctness, tell the user if the information is correct and complete or 
not, and then store the information. During a simulation, the DBSS must be able to 
receive a request from the HDS, locate the requested information, and then send the 
information to the HDS. 

2. Performance and Physical Parameters 

What are the operating characteristics of the DBSS, such as: size, accuracy, data 
flow rate, speed, storage capacity? What performance parameters are critical to the 
system? The DBSS must be of sufficient size that it can run on the available computers 
and servers of the end user. Since the DBSS uses Excel spreadsheets, which are small and 
only take up a few megabits, they should not affect any modern computer or operating 
system from running them. The critical system performance parameters follow the line: 
1) the DBSS must receive information from the new location and be able to tell the user 
if the information is correct and complete within a specific timeframe, 2) the DBSS must 
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be able to store a specific amount of information, and 3) the DBSS must be able to send 
data to the HDS during a simulation in a specific timeframe. 

3. Operational Deployment or Distribution 

How much equipment, personnel, hardware, software, training, facilities, and 
transportation are required for the expected location of the DBSS? What is being 
distributed? When does the DBSS become operational? The DBSS requires equipment, 
personnel, hardware, and software to operate. The DBSS requires some form or 
interaction, whether automated (such as a webpage) or in person (such as a site visit or 
video conference) with the new location to inform the user of the information required to 
construct the DBSS for a new location. It requires a storage device, such as a server or 
computer, to be stored on and network so that individuals can access the HDS and DBSS. 
It requires an operating system, such as Windows or OSX, to run Microsoft Office for 
Excel. It requires a facility for personnel to work from, such as an office. It required 
several personnel: one person fa mi liar with hurricane preparation operations and 
emergency management activities to perform a quality check on the information received 
from the user to ensure the information is complete and correct. This person can perform 
a site visit if required. It requires a programmer to write the code that will reference the 
collected information in the DBSS. This programmer can be located almost anywhere 
within reason, they must have the ability to interact with the person performing the 
quality check of the DBSS and a manager. One management person is required to 
oversee the DBSS progress and integration into the HDS. The DBSS must interact with 
the new location in the design step of the waterfall process model so that it can collect the 
required information from the user. The DBSS should be distributed as a part of the entire 
HDS package to the end user. The DBSS becomes fully operational when all of the 
required information has been collated, is correct, complete, and is integrated with the 
HDS. 


4. Operational Life-Cycle 

What is the anticipated time that the DBSS will be in operation? Who will be 


operating the DBSS? The DBSS will be in operation for the entire operational life-cycle 
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of the HDS by the end user. Initially, the DBSS will be used by a developer to collect the 
required information. The operational life-cycle of the DBSS is not known. It will be 
determined by MARFORRES and the MFRHTC in Hialeah. It is anticipated that it will 
be used for at least several years, until the scenario build within the HDS become 
obsolete. 

5. Utilization Requirements 

What is the anticipated number of hours the DBSS will be used? How will the 
DBSS be used? The DBSS will always be used in conjunction with the HDS. The 
anticipated number of hours of the DBSS is not known. It will be determined by 
MARFORRES and the MFRHTC in Hialeah. MARFORRES uses the HDS a few times 
per year to train their personnel in group exercises and to train individuals on a case by 
case basis. The MFRHTC in Hialeah will use the HDS in a similar manner as 
MARFORRES. After distribution, the end user will operate the DBSS and have the 
ability to change and adapt the DBSS to their situation or scenario. 

6. Effectiveness Factors 

Effectiveness factors relate to the figures-of-merit of the system requirements, 
such as, availability, failure rate, downtime, operator skill level, cost, and schedule. The 
effectiveness factors must be defined, measurable, and relate to the operational situation. 
The DBSS is effective as long as it can collect the required information from the new 
location, check the information for completeness and correctness, inform the user if more 
information is required, store the information in the correct location, and then enable 
access to the information during a simulation of the HDS. 

7. Environmental Factors 

What environment is the DBSS projected to operate in? The DBSS will operate 
on a server or computer wherever it is being stored and be accessible through the internet. 
The environmental factors must be acceptable for the server or computer to operate 
effectively. 
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C. DBSS’S MAINTENANCE AND SUPPORT REQUIREMENTS 

The maintenance and support concept developed should define the characteristics 
of maintainability, human factors and safety, reliability, constructability, produce ability, 
sustainability, supportability, and disposability Blanchard and Fabrycky (2011). Since the 
DBSS is a sub-system of the HDS, the maintenance and support requirements are 
relatively small. During all life-cycle phases of the HDS, maintaining and supporting the 
DBSS is simple. The user must ensure that the computer that they are operating on is 
working and the software operating on the computer or server is supported. Sustaining 
the DBSS requires the information collected and stored inside it to be evaluated 
periodically to ensure that it aligns with the HDS scenario for the location. Disposability 
requires only that the HDS program and DBSS information be archived for possible 
review in the future or deleted entirely. 

D. IDENTIFYING, ESTABUISHING, AND PRIORITIZING TECHNICAL 

PERFORMANCE MEASURES FOR THE DBSS 

Technical performance measures (TPMs) are quantitative values, numbers, or 
metrics that describe the system performance. They can be predicted, measured, or 
estimated and are measures of the attributes or characteristics inherent to the design of the 
system. The objective of a TPMs is to “influence the system design process to 
incorporate the right attributes or characteristics to produce a system that will ultimately 
meet customer requirements effectively and efficiently” (Blanchard and Fabrycky 2011, 
82). TPMs should be identified and prioritized by the stakeholders, including the 
customer, designed, producer, suppliers, and key management personnel to ensure that 
they capture the most important objectives of the system design. Possible TPMs for the 
DBSS would include: 

• processing time (dd:hh:mm:ss) for the system to receive and send 
information to the user when collecting information 

• processing time (milliseconds) for the system to receive a request from the 
HDS and then locate and send the information during a simulation 
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• operational availability (99% minimum) when the user wishes to use the 
HDS 

• size (megabits of storage) 

• human factors (less than 1% error rate) when determining if the 
information the user sends is correct and complete 

E. FUNCTIONAL ANALYSIS AND ALLOCATING REQUIREMENTS TO 

COMPONENTS OF THE BBSS 

A functional hierarchy, function description, functional flow block diagram, 
physical block diagram, and components description of the DBSS will be used to explore 
the underlying “what” a system must do and will help understand the functions, sub¬ 
functions, and components of the DBSS and their relationships. 

Creating a functional hierarchy for the DBSS defines the basics for a functional 
analysis and displays a view of the HDS’s functional architecture. It organizes the 
functions into sub-systems in a top-down, highest to lowest logical order, and shows how 
elements in the systems relate. Though functional hierarchies have significant importance 
they have several limitations. The most important limitation is the inability to relate and 
indicate the flow of functions and sub-functions in time and space. FFBDs describe the 
structure of the system operating requirements into a functional architecture by 
illustrating organizational and functional interfaces (Blanchard and Fabrycky 2011). 
Figure 26 illustrates a functional hierarchy with the first and second level functions of the 
DBSS. Table 2 defines the functions. Figure 27 uses the DBSS functions to create an 
FFBD for creating a DBSS. 
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Figure 26. Functional Hierarchy for the DBSS 


Table 2. DBSS Function Descriptions 


DBSS Functional Descriptions 

Functions 

Description 

Collect Information 

Iterative process of collecting the required information, 
determining if the information is correct or not, and accepting 
or rejecting the information 

1 

Inform User of Required Information 

Process of telling the user what information the DSS requires 

Receive Information from User 

Process of receiving the information from the user 

Determine if Information from User 

is Correct and Complete 

Process of determining if the information received from the 
user is correct and complete 

Accept Information from User 

Process of accepting the information form the user 

Reject Information from User 

Process of rejecting the information from the user 

Store Data and Information 

Process of formatting and storing the data and information 

received from the user 

1 

Format Information from User 

Process of formatting the data and information received from 

the user 

Place Information in Correct Location 

Process of putting the information from the user in the correct 

location in the DSS 

Enable Access to Information 

Process of allowing access to the stored information from 

outside sources 

■ 

Receive Request for Information 

Process of receiving a request for information 

Locate Requested Information 

Process of locating the requested information within the DSS 

Send Requested Information 

Process of sending the requested information to the requester 


In Figure 27, the DBSS first informs the user of the information required by the 
DBSS. The user then collects the required information from their planning and operating 
documents, then sends the information to the DBSS. The DBSS receives the information, 
formats it, places it into the correct storage location, and then determines if the 
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information is complete and correct. Complete and correct insures that all information 
required was received and is accurate. If the information is complete and correct, the 
DBSS accepts the information and stores it in its storage system. If the information is not 
complete and correct, the DBSS rejects the information and informs the user and requests 
additional information. This loop continues until the user sends the correct information in 
its completeness to the DBSS. After all of the information has been accepted, the DBSS 
waits until a simulation is being conducted and the HDS requests information from the 
DBSS. Then the DBSS receives the request, locates the information, and sends the 
information to the HDS. The DBSS continues to do this throughout the simulation until it 
is complete. 



Figure 27. FFBD for Creating the DBSS 


After creating a functional hierarchy, defining the functions, and creating a FFBD 
for creating the DBSS, the components of the DBSS begin to materialize. Figure 28 
illustrates a physical flow block diagram where the components of the DBSS can be seen. 
Physical flow block diagrams are similar to functional hierarchies except they show the 
components instead of the functions. Table 3 describes the components. 
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Figure 28. Physical Block Diagram for the DBSS and its Components 
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Table 3. DBSS Component Descriptions 


DBSS Component Descriptions 

Components 

Description 

Interface 

Piace where the user interacts with the DSS (webpage or server 
iocation) 


Seiection Options 

Options the user has to seiect from on the interface (iinks or 
buttons on the webpage) 

Information Storage System 

Storage system for the DSS 


Information Storage 

Piace where the information coiiected from the user is stored 
(spreadsheets) 

Information Piacement System 

System that piaces the information coiiected from the user into 
the appropriate iocation 


Information Separator 

Separates the information into the correct storage area 
(spreadsheet) 

Information Piacer 

Piaces the information after it has been separate into the 
correct iocation inside the storage system (inside the 
spreadsheet) 

Information Locator 

Locates information in the storage system 

Information Error Checking System 

Systems that checks the information for error is grammar, 
speiiing, and iogic (it is worded right, speiied correctiy, and does 
it make sense) 


Word, Speiiing, & Grammar Checker 

Speiiing and grammar checking (think of it use in Microsoft 

Word) 

Logic Checker 

Checks information to determine if it makes sense 

Information Compiier 

Compiies information into after speiiing, grammar, and iogic 
checking back into its storage iocation 

If not complete and correct sends notice to messaging system 

Messaging System 

System that sends and receives information to the user 


Information Receiver 

Receives information (inbox) 

Information Informer & Sender 

Sends information (outbox) 

Message Information Storage 

Storage system for the messaging service (log record to review) 


All functions identified in the functional hierarchy are associated with at least one 
component that can be displayed in a traceability matrix. In the traceability matrix, the 
functions are listed on the left and the components at the top. Functions and components 
that are associated together are designated with an “X.” Table 4 displays the traceability 
matrix for the DBSS. If a function or component was not listed with an “X,” then it is not 
required or the matrix is incomplete. 
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Table 4. Traceability Matrix for the DBSS 


1 Traceability Matrix for the DBSS 

Functions 

Components 

Interface 

Information 

Storage 

System 

Information 

Placement 

System 

Information 

Error 

Checking 

System 

Messaging 

System 

Collect Information 



Inform User of Required Information 

X 




X 


Receive Information from User 

X 

X 



X 


Determine if Information from User is 




V 



Correct and Complete 




A 



Accept Information from User 

X 



X 

X 


Reject Information from User 

X 



X 

X 

1 Store Data and Information 



Format Information from User 


X 

X 

X 

X 


Place Information in Correct Location 


X 

X 

X 


1 Enable Access to Information 



Receive Request for Information 

X 




X 


Locate Requested Information 


X 

X 




Send Requested Information 

X 




X 


Further detail the mapping of functions to components leads to functional 
packaging. This method details how the operational modes of the DBSS related to the 
functions, sub-functions, and components. Figure 29 illustrates this process. 



Figure 29. Functional Packaging of the DBSS into Components 


56 




















F. BBSS SYSTEM TRADE-OFF ANALYSIS 

A system trade-off analysis is conducted in order to make decisions regarding the 
evaluation of technologies, components, subsystems, packaging schemes, degree of 
automation, type of testing and evaluation, maintenance and support processes, storage 
locations, logistics, and so on in the system design process. To accomplish a system 
trade-off analysis the problem must be defined, then measures identified to which the 
alternatives will be measured (the applicable TPMs), an evaluation technique is selected 
to model the process, each alternative is evaluated, then a sensitivity analysis is 
conducted, and finally a determination on the best alternative (Blanchard and Fabrycky 
2011). Figure 30 illustrates the system an example trade-off analysis process. The trade¬ 
off analysis for the DBSS was relatively simple, either modify the programming code and 
change the information inside the code for each new location or create a static storage 
system (the DBSS) that the programming code would reference. Since the latter was a 
well-established solution with which the developers (NPS team) were familiar, it was 
chosen. 
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Figure 30. Example Trade-off Analysis Process. Adapted from Blanchard and 

Fabrycky (2011). 


Due to the degree of human interaction with the DBSS, the degree of automation 
should be examined to determine what can be automated and what requires a human. In 
future versions of the HDS (version three and beyond), automated systems can fulfill 
several tasks that in previous versions were conducted by humans. Primarily the data 
collection methods can be streamlined by the use of automation. Site visits to new 
locations are not required to collect information. A webpage listing the spreadsheets with 
a detailed description and examples can be posted to show the new location and what 
information is required. If a webpage is not used, then an email, telephone conversation. 
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or video conference can be conducted. An artificial intelligence or program can process 
the information and determine if it is complete, but a human must conduct a sanity check 
and verify that the information is correct. All of these methods can save time, money, and 
resources. 

G. BBSS CONCEPTUAL DESIGN REVIEW 

The conceptual design review is an evaluation function that ensures that the 
system design is correct and can progress to the next step, preliminary design. Figure 31 
illustrates the overall conceptual design for the DBSS. 


Database Support System 



Figure 31. DBSS Conceptual Design 


This step includes both reviewing the day-to-day operations as well as the data 
and documentation of the overall system design. During this process, the design is 
reviewed for compliance with the system requirements and if the design satisfies the 
requirement it is approved and progresses. If the design does not meet the system 
requirements, corrective actions are taken to initiate a design review to determine a path 
forward and what must be done to correct the issues. 
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This chapter detailed the steps of a conceptual design for the DBSS as defined by 
Blanehard and Fabrycky (2011). Future versions of the DBSS should use this conceptual 
design and the eoneeptual design proeess as a basis for developing the DBSS further and 
possible automations of its functions. 
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VI. SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS 


A. SUMMARY AND CONCLUSIONS 

This thesis focused on the MFRHTC located in Hialeah, Florida, and used it to 
accomplish four objectives: 1) use a mission engineering analysis process to evaluate and 
analyze the decisions and actions that the commander and staff of the MFRHTC in 
Hialeah must make in preparation for a hurricane and possible evacuation of the HTC, 2) 
use the decomposition of the mission space to identify the types of information and 
resources necessary for these operations, 3) create a static database for the development 
of future HDSs, and 4) detail and create a conceptual design for the DBSS. 

Both mission and system engineering are powerful tools that can be used to 
examine the information and resources requirements and the decision and actions that the 
commander of a MFRHTC must make in hurricane preparation operations. The 
information, decisions, and actions feed into the spreadsheets of the DBSS. The DBSS is 
essential to the further development of the HDS because it allows for an easier collection, 
handling and storage of the information, decisions, and actions required in hurricane 
preparation operations. In order to create a functioning DBSS, it is necessary to structure 
the requirements process of the DBSS. Doing so illustrates the functions and components 
required for the DBSS. Creating a conceptual design for the DBSS makes it easier to 
understand and develop DSSs for the MFTHTC and other organizations. 

The methodology in Chapter III describes how ME, SE, and the MDMP can be 
applied to decompose the HDS and develop a DBSS for future HDSs. Additionally, the 
methodology helped analyze the methods, purpose, and type of data and information 
required for hurricane preparation operations. Chapter III also explains how SE, the U.S. 
Army design methodology, and the MDMP combine together to form the ME process. 

The analysis in Chapter IV details how the methodology was used to examine the 
problem and determine the information requirements and results. It identifies the type of 
information and resources necessary for hurricane preparation operations, along with the 
key decisions and follow on actions that the commander can make. The information was 
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included in the spreadsheet of the DBSS. Chapter IV also breaks down the DBSS, 
illustrating both the functions and components of the DBSS, then maps the functions to 
the components. 

Determining the information requirements, key decisions, and actions that the 
MFRHTC in Hialeah must take during hurricane preparation operations was critical to 
the development of the DBSS. The key decisions include: 1) Prepare the ADVON party, 
2) Storm proof the HTC and personal property, 3A) Deploy the ADVON party to the 
alternate command and control location and authorize a voluntary evacuation, 3B) 
Prepare and stand up the RBE, 4A) Secure the HTC and issue a mandatory evacuation 
order, 4B) Shelter in place, and 5) Transfer command and control to the alternate 
headquarters. These key decisions enabled the construction of a decision tree, which 
determined the decision logic and architecture of the programming code. 

Chapter V details a conceptual design for the DBSS, which establishes the 
foundation for understanding the customer need. The current version of the HDS was 
specific to MARFORRES in New Orleans. It could not adapt to new locations; therefore, 
the HDS needed to be transformed into a version that would be adaptable to different 
locations. System planning and architecting was conducted to establishing a system 
engineering management plan and functional baseline for the DBSS. A system trade-off 
and feasibility analysis was detailed, resulting in two alternatives that were examined: 1) 
replacing the location specific information in the programming code or 2) removing the 
location specific information from the code and placing it in a storage location where the 
code you reference the information when needed during a simulation. Alternative two 
was chosen because it was already a well-established practice in the software industry. 
The system operating requirements were examined and determined by evaluating the 
DBSS through the commonly listed seven areas: 1) mission definition, 2) performance 
and physical parameters, 3) operational deployment or distribution, 4) operational life- 
cycle, 5) utilization requirements, 6) effectiveness factors, and 7) environmental factors 
as identified by Blanchard and Fabrycky (2011). The maintenance and support 
requirements of the DBSS were determined to be small throughout the HDS life cycle, 
requiring a storage device to store the program, a computer to run the program, and 
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periodic updates to the information in the DBSS to ensure it still applies to the 
operational scenario. Lastly, a conceptual design review was detailed to ensure that the 
alternative design selected is correct and can progress to the next step, preliminary 
design. 

B. RECOMMENDATIONS FOR FUTURE RESEARCH 

Beyond this thesis, areas of future research and work should begin with a 
preliminary design, then continue to a detailed design of the DBSS. Additionally, and 
detailed design should be completed for the HDS to ensure proper documentation is 
captured. If any new products or developments are added to the HDS, they should have a 
conceptual, preliminary, and detailed designs completed. 

Areas of further research and work for the HDS may include: human factors 
analysis of the user interface, finding additional uses and applications of the HDS, and 
the use of an artificial intelligence or program to assist the user in making real-time 
decisions during a simulation. Human factors analysis involves studying the user 
interface to determine areas of improvement. For these studies, it is important to 
understand the human eye movements in relation to the visual view, which allows 
researchers to measure where the eyes are looking, for how long, what the user is focused 
on, and how often areas in the visual view are revisited. Exploring the uses and 
applications of the HDS opens the door to finding different organizations that could 
benefit from the HDS, such as the United States Army Corps of Engineers, the Eederal 
Emergency Management Agency, and numerous cities and emergency management 
center. Additionally, evaluating the current uses of the HDS at MAREORRES can 
provide useful information and possible improvements. Eastly, a study on the use of an 
artificial intelligence to assist the user in making decisions during a simulation. This tool 
would have to be in context with developing decision support for real-time decisions. 
Additionally, an artificial intelligence could be developed to aid in measuring 
performance of the user, identifying optimal (good or bad) decisions and use the 
information to provide more direct feedback to the user. 


63 



Areas of further research and emphasis for the DDS should include the creation of 
a digital interface, such as a web page, and a study of the use of automation to collect 
location information from the user. Using a digital interface allows the user and human to 
interact without the cost of traveling to meet one another. Currently, a human is required 
to receive the location information from the user, input the information into the correct 
spreadsheet, and check to see if the information is correct and complete. A study about 
the use of an artificial intelligence to help automate the information collection, 
placement, and storage processes would reduce the amount a human is involved and save 
costs. 
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APPENDIX. HURRICANE DECISION SIMULATOR - DETAILED 

SIMULATION EXAMPLE 


This appendix details an example of one simulation in the MARFORRES HDS. It 
allows the reader to experience the HDS without using the program. The MARFORRES 
HDS is available from http://eddy.nps.edu/hurricaneSim/simulation. The simulation starts 
in Figure 32 with the initial TC update and the user is prompted with the first decision, 
deploy the AD VON. 



Figure 32. Simulation Start. Source: U.S. Marine Forces Reserve (2016). 


The user decides not to make the decision and continues the simulation. The user 
continues through the first three TC updates, shown in Figure 33 through Figure 35, 
before he or she decides to make the first decision. Throughout the simulation, the 58- 
mph wind speed probability is displayed on the map, which the user uses to determine if 
and when to make a decision. The user can also use the wind speed probabilities of 39 
and 74 mph along with the first error winds cone probability. TC updates are presented in 
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six-hour increments with updated time to land fall predictions and wind speed 
probabilities of what the user has selected. 


About Kelp Shere 


HURRICANE DEaSION SIMULATOR 


PROBABILITIES (ofWInds Exceeding Threshold) ("t, 


Record of Events 


39 mph 


58 mph 


74 mph 


Cone 12 Aug 1200 


Current i I24hrs is% 

6 hrs ago i n/a 12% 

Initial Storm Update 


Decision Mill 


Do you want to deploy the 
ADVON (19 personnel) for 
about $25,000? 


NO. CONTINUE 



70% 

60% 

50 >. 

40% 

1 

30% 


120*hour probability of 58 mph winds affecting NOLA: 15% 

TOGGLE MAP VIEW 

Expected Landfall Storm Center Radius of Max Winds 

124 hrs (at 29.9*N)c92.5»W) 25.6*N x 77.6»W 3S mi 

Max Sus. Winds 
31 mph 




AUTO ADVANCE ® 

6 hrs SCI 

Current 


1 20% 
10 % 
5% 


CURRENT UPDATE 12 Aug 1200 




NoAcOons i Details 


Figure 33. First Update. Source: U.S. Marine Forces Reserve (2016). 


Help 0 Share •: 


Record of Events 0 


HURRICANE DECISION SIMULATOR 


PROBABILITIES (ofWinds Exceeding Threshold) (Ty 
39 mph 74 mph 


12 Aug 1800 



Figure 34. Second Update. Source: U.S. Marine Forces Reserve (2016). 
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HURRICANE OEaSION SIMULATOR 


About H«lp Shore 
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Current 


Figure 35. Third Update. Souree: U.S. Marine Forees Reserve (2016). 


After the user sees the third TC update, the user deeided to make the first and 
seeond decisions, deploy ADVON to the alternate headquarters location and deploy 
Liaison Officers to the local agencies based on a 26% probability of receiving 58 mph 
winds at 106 hours to land fall, shown in Figure 36 and Figure 37. The user then 
continues through the fourth, fifth, and sixth TC updates, seen in Figure 38 through 
Figure 40. 
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Figure 36. Third Update with ADVON Deployed. Source: U.S. Marine Forces 

Reserve (2016). 


Help 


Record of Events <2) 

Current t := 106 hrs 26% 

Deployed ADVON 

Deployed liaison officers 

RBE, ERS, and CAT rosters are validated 

6 hrs ago t I20hrs 13% 

12 hrs ago t I24hrs 15% 


18 hrs ago t rt/a 12 % 

Initial Storm Update 


Decision Hill 


Do you want to deploy the rest 
of the ERS to the alternate HQ 
(46 personnel) for about 
$ 100 , 000 ? 


m 


NO. CONTINUE 



HURRICANE DECISION SIMULATOR 


PROBABILITIES (ofVifindsExceedingThreshold) 
39 mph 74 mph 


13 Aug 0000 


CURRENT UPDATE l3AugOOOO •= Actions 

120-hour probability of 58 mph winds affecting NOLA: 26% 


Expected Landfall 
106hrs(at31.9*Nx88.1*W) 


Storm Center Radius of Max Winds Max Sus. Winds 
24.7*Nx80.4’W 3Sml 38 mph 


TOGGLE MAP VIEW 
AUTO ADVANCE ® 


Figure 37. Third Update with Liaison Officers Deployed. Source: U.S. Marine 

Forces Reserve (2016). 
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Figure 38. Fourth Update. Source: U.S. Marine Forces Reserve (2016). 


Help Share •]) 


Record of Events 


HURRICANE DECSION SIMULATOR 


PROBABILITIES (of winds Exceeding Threshold) 0 
39 mph 74 mph 


13 Aug 1200 


Current t is 93 hrs 19% 

Participate in teleconference with NOAA... 

6 hrs ago i is 99 hrs 13% 

BPT provide staff updates 

12 hrs ago i is I06hrs 26% 

Deployed ADVON 

Deployed liaison officers 

R8E, ERS, and CAT rosters are validated 

18 hrs ago i laohrs 13% 


24 hrs ago t 124hrs 1S% 


Decision MMI 


Do you want to deploy the rest 
of the ERS to the alternate HQ 
(46 personnel) for about 
$ 100 , 000 ? 


NO. CONTINUE 



CURRENT UPDATE 13Aug1200 is Actions 

120-hour probability of 58 mph winds affecting NOLA: 19% 

Expected Landfall 
93hrs(at 29.8*Nx89.9*W) 


Storm Center Radius of Max Winds Max Sus. Winds 
24.8*Nx83.0*W 30mi 86 mph 


TOGGLE MAP VIEW 
AUTO ADVANCE ® 




Current 


Figure 39. Fifth Update. Source: U.S. Marine Forces Reserve (2016). 
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HURRICANE DECISION SIMULATOR 


PROBABILITIES (of winds Exceeding Threshold) ^ 



Figure 40. Sixth Update. Source: U.S. Marine Forces Reserve (2016). 


After the sixth TC update, the user decided to make the decision to deploy the rest 
of the ERS team to the alternate headquarters location, based on a 14% probability of 
receiving 28 mph winds at 84 hours to landfall. The user then continues through the 
seventh and eighth TC update, shown in Figure 41 and Figure 42. 
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Figure 41. Seventh Update. Source: U.S. Marine Forces Reserve (2016). 
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Figure 42. Eighth Update. Source: U.S. Marine Forces Reserve (2016). 
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Figure 43. Ninth Update with RBE Activated. Source: U.S. Marine Forces 

Reserve (2016). 

After the ninth TC update the user decides to make the decision to activate the 
RBE, based on the 58% probability of receiving 58 mph winds at 73 hours before land 
fall, shown in Figure 43. 
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Figure 44. Tenth Update. Source: U.S. Marine Forces Reserve (2016). 


After the tenth TC update, shown in Figure 44, the user decided to make the 
decision to order an evacuation based on a probability of 22% of receiving 58 mph winds 
at 65 hours before landfall. The user then continues through the eleventh and makes the 
decision and twelfth TC updates, shown in Figure 45 and Figure 46. 
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Figure 45. Eleventh Update with Evacuation Order Issued. Source: U.S. Marine 

Eorces Reserve (2016). 
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Eigure 46. Twelfth Update. Source: U.S. Marine Eorces Reserve (2016). 
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Figure 47. Thirteenth Update. Source: U.S. Marine Forces Reserve (2016). 


After the thirteenth update, the user makes the decision to transfer C2 to the 
alternate headquarters based on a probability of 9% of receiving 58 mph winds at 47 
hours before landfall, shown in Figure 47. This is the last decision the user is prompted to 
make. The user then proceeded through the fourteenth through seventeenth TC updates 
until the simulation is complete, shown in Figure 48 through Figure 51. 
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Figure 48. Fourteenth Update with C2 Transferred. Souree: U.S. Marine Forces 

Reserve (2016). 
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Figure 49. Fifteenth Update. Source: U.S. Marine Forces Reserve (2016). 
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Figure 50. Sixteenth Update. Source: U.S. Marine Forces Reserve (2016). 
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Figure 51. 


Seventeenth Update. Source: U.S. Marine Forces Reserve (2016). 
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After the simulation has concluded, the user receives the results, shown in Figure 
52, and feedback, shown in Figure 53. The user can also review the entire simulation and 
analyze the TC and when he or she made decisions. 


:: 
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Results: 

Although the storm did not make landfall near 
NOIA NOLA experienced 46 mph winds (tropical 
storm) on 14 Aug 1800. hours after the NHC's first 
forecast of this storm. 

The storm surge was 4.2 feet and occurred at low 
tide. 

You deployed the ADVON 42 hours before NOLA 
experienced 39 mph winds. 

You deployed liaison officers to local municipal 
£OCs 42 hours before NOLA experienced 39 mph 
winds. 

You deployed the rest of the ERS to the alternate 
HQ 24 hours before NOLA experienced 39 mph 
winds. 

You aaivated the remain-behind element (RBE) 

18 hours before NOLA experienced 39 mph 
winds. 

You issued orders to evacuate 12 hours before 
NOLA experienced 39 mph winds. 

You transferred C2 to the alternate HQ while 39 
mph winds were affecting NOLA. 
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Figure 52. Simulation Results. Source: U.S. Marine Forces Reserve (2016). 
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Feedback: 

• The ADVON established communications before 
the rest of the ERS team arrived. 

• ERS established alternate HQ by the time MFR 
personnel arrive. 

• The RBE was identified very late. 

• MFR personnel were evacuating as high winds 
from the storm were arriving In NOLA. This put 
MFR personnel in serious danger. 

• C2 was transferred to the alternate HQ very 
late. 

• MFR headquarters in NOLA can be used. 

• Mission essential functions can be performed. 

• MFR personnel anxious to return to NOLA given 
that the storm was relatively mild. 

• A return to NOLA will be scheduled for 3 days. 

• G1 has to generate about 3000 sets of travel 
orders for the evacuation. 

• The direct cost of the evacuation, Including 
deploying the ADVON and ERS. is $1,475,000 
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Figure 53. Simulation Feedback. Source: U.S. Marine Forces Reserve (2016). 
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SUPPLEMENTAL 


The Database Support System Matrices include: actions, announcements, decision 
announcements, decision costs, decision storm, decision timing, decisions, surge results, 
and wind results. 

The actions spreadsheet contains all the actions the MFRHTC must complete 
when a decision is made. The time and actions are recorded in the record of events and 
displayed in the feedback at the end of the simulation. 

The announcements spreadsheet details announcements that pop up if the TC 
meets specified conditions based on wind cone probability, probability of wind speed, 
probability of surge level, and the expected TC time to landfall. If the specific condition 
is met, the time is recorded in the record of events, a pop up event is displayed and then is 
listed in the feedback at the end of the simulation. For example, announcements may 
describe actions by the MDOEM, or TC events like hurricane-force winds in Miami. 

The decision announcements spreadsheet describes the announcements that pop 
as a result of the time when the user selects decisions in relation to announcements. For 
example, these describe any conflicts with local state, county, and MDOEM operations. 

The decision costs spreadsheet details the fixed and variable cost of making 
each decision. Eixed costs are a one-time cost while variable costs are dependent on the 
wind speed and surge, which affect the duration of some activities such as an evacuation. 

The decision storm spreadsheet describes the consequences of the time the user 
makes decisions in relation to the surge and winds conditions at the time. The events are 
listed in the feedback at the end of the simulation. 

The decision timing spreadsheet specifies the conditions, announcement, and 
results in the event a decision is made too soon after an earlier decision. If a decision is 
made and the specified time has not elapsed, a pop up is triggered letting the user know 
the results of the decision at that time. The events are listed in the feedback at the end of 
the simulation. 
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The decisions spreadsheet contains the key decisions that the user is prompted to 
make in the HDS. When the user selects a decision, the time is recorded and information 
is sent to five interaction points. Depending on the time the user makes the decision and 
the position of the TC, announcements and popups may be triggered. The key decisions 
are detailed in the following section of this chapter. 

The winds and surge spreadsheets specify the wind and surge thresholds with 
their associated decisions the MDOEM would make and other consequences. If the 
threshold is reached, the event is listed in the feedback at the end of the simulation. 

Please contact the Dudley Knox Library if you are interested in retrieving the 
supplemental materials. 
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